+++ /dev/null
-The Win32 backend in GTK+ is not as stable or correct as the X11 one.\r
-\r
-For prebuilt runtime and developer packages see\r
-http://ftp.gnome.org/pub/gnome/binaries/win32/\r
-\r
-Notes on using OpenGL (GtkGLArea/GdkGLArea) on Win32\r
-====================================================\r
-Note that on Windows, if one is running Nahimic 3 on a system with\r
-nVidia graphics, one needs to stop the "Nahimic service" or insert\r
-the GTK application into the Nahimic blacklist, as noted in\r
-https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/297952/nahimic-and-nvidia-drivers-conflict/2334568/\r
-if using programs that utilise GtkGLArea and/or GdkGLArea, or use\r
-GDK_GL=gles if you know that GLES support is enabled for the build.\r
-\r
-This is a known issue, as the above link indicates, and affects quite\r
-a number of applications--sadly, since this issue lies within the\r
-nVidia graphics driver and/or the Nahimic 3 code, we are not able\r
-to rememdy this on the GTK side; the best bet before trying the above\r
-workarounds is to try to update your graphics drivers and Nahimic\r
-installation.\r
-\r
-Building GTK+ on Win32\r
-======================\r
-\r
-First you obviously need developer packages for the compile-time\r
-dependencies: GDK-Pixbuf, Pango, atk, glib, gettext-runtime, libiconv at least.\r
-See http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies .\r
-\r
-For people compiling GTK+ with Visual C++ or later, it is recommended that\r
-the same compiler is used for at least GDK-Pixbuf, Pango, atk and glib\r
-so that crashes and errors caused by different CRTs can be avoided. Currently\r
-building with Visual Studio 2008 or later is supported, either via Visual Studio\r
-project files or via the Meson build system, as described in the below sections.\r
-For Visual Studio 2008, 2010, a special setup making use of the Windows 8.0 SDK\r
-is required, see at the bottom of this document for guidance.\r
-Interchanging between Visual Studio 2015, 2017 and 2019 builds should be fine\r
-as they use the same CRT (UCRT) DLLs.\r
-\r
-After installing the dependencies, there are two ways to build GTK+\r
-for win32.\r
-\r
-1) GNU tools, ./configure && make install\r
------------------------------------------\r
-\r
-This requires you have mingw and MSYS.\r
-\r
-Use the configure script, and the resulting Makefiles (which use\r
-libtool and gcc to do the compilation). I use this myself, but it can\r
-be hard to setup correctly.\r
-\r
-The full script I run to build GTK+ 2.16 unpacked from a source\r
-distribution is as below. This is from bulding GTK+ 2.16.5. I don't\r
-use any script like this to build the development branch, as I don't\r
-distribute any binaries from development branches.\r
-\r
-# This is a shell script that calls functions and scripts from\r
-# tml@iki.fi's personal work envíronment. It is not expected to be\r
-# usable unmodified by others, and is included only for reference.\r
-\r
-MOD=gtk+\r
-VER=2.16.5\r
-REV=1\r
-ARCH=win32\r
-\r
-THIS=${MOD}_${VER}-${REV}_${ARCH}\r
-\r
-RUNZIP=${MOD}_${VER}-${REV}_${ARCH}.zip\r
-DEVZIP=${MOD}-dev_${VER}-${REV}_${ARCH}.zip\r
-\r
-HEX=`echo $THIS | md5sum | cut -d' ' -f1`\r
-TARGET=c:/devel/target/$HEX\r
-\r
-usedev\r
-usemsvs6\r
-\r
-(\r
-\r
-set -x\r
-\r
-DEPS=`latest --arch=${ARCH} glib atk cairo pango libpng zlib libtiff jpeg`\r
-PROXY_LIBINTL=`latest --arch=${ARCH} proxy-libintl`\r
-\r
-PKG_CONFIG_PATH=\r
-for D in $DEPS; do\r
- PATH=/devel/dist/${ARCH}/$D/bin:$PATH\r
- [ -d /devel/dist/${ARCH}/$D/lib/pkgconfig ] && PKG_CONFIG_PATH=/devel/dist/${ARCH}/$D/lib/pkgconfig:$PKG_CONFIG_PATH\r
-done\r
-\r
-LIBPNG=`latest --arch=${ARCH} libpng`\r
-ZLIB=`latest --arch=${ARCH} zlib`\r
-LIBTIFF=`latest --arch=${ARCH} libtiff`\r
-JPEG=`latest --arch=${ARCH} jpeg`\r
-\r
-patch -p0 <<'EOF'\r
-EOF\r
-\r
-lt_cv_deplibs_check_method='pass_all' \\r
-CC='gcc -mtune=pentium3 -mthreads' \\r
-CPPFLAGS="-I/devel/dist/${ARCH}/${LIBPNG}/include \\r
--I/devel/dist/${ARCH}/${ZLIB}/include \\r
--I/devel/dist/${ARCH}/${LIBTIFF}/include \\r
--I/devel/dist/${ARCH}/${JPEG}/include \\r
--I/devel/dist/${ARCH}/${PROXY_LIBINTL}/include" \\r
-LDFLAGS="-L/devel/dist/${ARCH}/${LIBPNG}/lib \\r
--L/devel/dist/${ARCH}/${ZLIB}/lib \\r
--L/devel/dist/${ARCH}/${LIBTIFF}/lib \\r
--L/devel/dist/${ARCH}/${JPEG}/lib \\r
--L/devel/dist/${ARCH}/${PROXY_LIBINTL}/lib -Wl,--exclude-libs=libintl.a \\r
--Wl,--enable-auto-image-base" \\r
-LIBS=-lintl \\r
-CFLAGS=-O2 \\r
-./configure \\r
---enable-win32-backend \\r
---disable-gdiplus \\r
---with-included-immodules \\r
---without-libjasper \\r
---enable-debug=yes \\r
---enable-explicit-deps=no \\r
---disable-gtk-doc \\r
---disable-static \\r
---prefix=$TARGET &&\r
-\r
-libtoolcacheize &&\r
-rm gtk/gtk.def &&\r
-(PATH="$PWD/gdk-pixbuf/.libs:/devel/target/$HEX/bin:$PATH" make -j3 install || (rm .libtool-cache* && PATH="/devel/target/$HEX/bin:$PATH" make -j3 install)) &&\r
-\r
-PATH="/devel/target/$HEX/bin:$PATH" gdk-pixbuf-query-loaders >/devel/target/$HEX/etc/gtk-2.0/gdk-pixbuf.loaders &&\r
-\r
-grep -v -E 'Automatically generated|Created by|LoaderDir =' <$TARGET/etc/gtk-2.0/gdk-pixbuf.loaders >$TARGET/etc/gtk-2.0/gdk-pixbuf.loaders.temp &&\r
- mv $TARGET/etc/gtk-2.0/gdk-pixbuf.loaders.temp $TARGET/etc/gtk-2.0/gdk-pixbuf.loaders &&\r
-grep -v -E 'Automatically generated|Created by|ModulesPath =' <$TARGET/etc/gtk-2.0/gtk.immodules >$TARGET/etc/gtk-2.0/gtk.immodules.temp &&\r
- mv $TARGET/etc/gtk-2.0/gtk.immodules.temp $TARGET/etc/gtk-2.0/gtk.immodules &&\r
-\r
-./gtk-zip.sh &&\r
-\r
-mv /tmp/${MOD}-${VER}.zip /tmp/$RUNZIP &&\r
-mv /tmp/${MOD}-dev-${VER}.zip /tmp/$DEVZIP\r
-\r
-) 2>&1 | tee /devel/src/tml/packaging/$THIS.log\r
-\r
-(cd /devel && zip /tmp/$DEVZIP src/tml/packaging/$THIS.{sh,log}) &&\r
-manifestify /tmp/$RUNZIP /tmp/$DEVZIP\r
-\r
-You should not just copy the above blindly. There are some things in\r
-the script that are very specific to *my* build setup on *my* current\r
-machine. For instance the "latest" command, the "usedev" and\r
-"usemsvs6" shell functions, the /devel/dist folder. The above script\r
-is really just meant for reference, to give an idea. You really need\r
-to understand what things like PKG_CONFIG_PATH are and set them up\r
-properly after installing the dependencies before building GTK+.\r
-\r
-As you see above, after running configure, one can just say "make\r
-install", like on Unix. A post-build fix is needed, running\r
-gdk-pixbuf-query-loaders once more to get a correct gdk-pixbuf.loaders\r
-file.\r
-\r
-For a 64-bit build you need to remove the gtk/gtk.def file and let it\r
-be regenerated by the makefilery. This is because the 64-bit GTK dll\r
-has a slightly different list of exported function names. This is on\r
-purpose and not a bug. The API is the same at the source level, and\r
-the same #defines of some function names to actually have a _utf8\r
-suffix is used (just to keep the header simpler). But the\r
-corresponding non-suffixed function to maintain ABI stability are not\r
-needed in the 64-bit case (because there are no older EXEs around that\r
-would require such for ABI stability).\r
-\r
-\r
-2) Microsoft's tools\r
---------------------\r
-\r
-There are VS 2008~2019 solution and project files to build GTK+, which\r
-are maintained by Chun-wei Fan. They should build GTK+ out of the box,\r
-provided that the afore-mentioned dependencies are installed. They will\r
-build GDK with the Win32 backend, GTK+ itself (with GAIL/a11y built in),\r
-the GAIL-Util library and the gtk-demo program. Please also refer to the\r
-README file(s) that reside in win32 on how to enable additional features\r
-that are not enabled by default, such as EGL support via libANGLE, which\r
-emulate the GL/EGL calls using Direct3D 9/11.\r
-\r
-Please refer to the following GNOME Live! page for a more detailed ouline\r
-on the process of building the GTK+ stack and its dependencies with Visual\r
-C++:\r
-\r
-https://wiki.gnome.org/Projects/GTK+/Win32/MSVCCompilationOfGTKStack\r
-\r
-Alternative 1 also generates Microsoft import libraries (.lib), if you\r
-have lib.exe available. It might also work for cross-compilation from\r
-Unix.\r
-\r
-I (Tor) use method 1 myself. Hans Breuer has been taking care of the MSVC\r
-makefiles. At times, we disagree a bit about various issues, and for\r
-instance the makefile.msc files might not produce identically named\r
-DLLs and import libraries as the "autoconfiscated" makefiles and\r
-libtool do. If this bothers you, you will have to fix the makefiles.\r
-\r
-If desiring to build binaries for ARM64 (aarch64), one needs to use the\r
-Visual Studio 2017 or 2019 solution files, or use Meson with a\r
-cross-compilation file, with a Windows 10 SDK that supports ARM64\r
-builds. At this point, building the introspection files is not supported\r
-for ARM64 builds, and you will need a Python 3.x interpreter and\r
-glib-compile-resources binaries that run on the build machine. For Visual Studio\r
-2017 ARM64 builds, do also check the Directory.Build.props file in $(srcroot)/win32/vs15\r
-indicates a Windows 10 SDK version that supports ARM64 builds exists on the build machine.\r
-\r
-For building ARM64 binaries with the Visual Studio projects, prior to the build,\r
-you may need to update gtk3-gen-srcs.props to pass in the variables GLIB_MKENUMS,\r
-GLIB_GENMARSHAL, GDBUS_CODEGEN and/or GLIB_COMPILE_RESOURCES in the nmake command line\r
-indicated by <GenerateRequiredSourcesBase> so that they point to the glib-mkenums,\r
-glib-genmarshal, gdbus-codegen and glib-compile-resources that will run on the build\r
-machine. You may also need to update gtk3-version-paths.props to update PythonDir to\r
-the installation of the Python 3.x interpreter that will run on the build machine. To carry\r
-out the actual build using the solution files, use the "Configuration Manager" to add the\r
-ARM64 build configs by copying the settings from the x64 configs, and then build the solution.\r
-The build instructions for such builds otherwise follow the standard Win32 (x86) and\r
-x64 builds, but you need to ensure that you have ARM64 builds of the various dependencies.\r
-\r
-It may still be possible to carry out the build and build the introspection files with Python 2.7.x\r
-using older versions of GLib and GObject-Introspection, but please note that this is not recommended\r
-and one is on his/her own by doing so.\r
-\r
-It is now supported to build with the Visual Studio projects directly\r
-from a GIT checkout. Run in a Visual Studio command prompt, in \r
-$(srcroot)/win32:\r
-\r
-nmake /f bootstrap-msvc.mak [PYTHON=...] [PERL=...] [FONT_FEATURES_DEMO=1] [FONT_FEATURES_USE_PANGOFT2=1] [USE_EGL=1]\r
-\r
-where PYTHON and PERL are the respective paths to the Python and PERL\r
-interpreters, if they are not in your %PATH%-they are both required to\r
-generate the full sets of project files, as well as the auxiliary build\r
-files and headers that is not available in a GIT checkout and must be\r
-generated prior to opening the project files.\r
-\r
-For FONT_FEATURES_DEMO, FONT_FEATURES_USE_PANGOFT2 and USE_EGL, please \r
-refer to win32\README_FEATURES_MSVC.md for more details, to enable \r
-features that is optional and not enabled by default (i.e. in the release\r
-tarballs).\r
-\r
-It is also possible to regenerate some or all of the visual studio \r
-projects with the following, if necessary:\r
-\r
-nmake /f generate-msvc.mak [PYTHON=...] [FONT_FEATURES_DEMO=1] [FONT_FEATURES_USE_PANGOFT2=1] [USE_EGL=1] <target>\r
-\r
-Where target can be (they will update all related VS2008~2022 projects):\r
-\r
-regenerate-demos-h-win32: Regenerate the gtk3-demo projects along with \r
-demos.h.win32, useful to enable or disable the Font Features demo.\r
-\r
-regenerate-gdk-vsproj: Regenerate all the GDK projects with broadwayd,\r
-useful to enable or disable EGL on Windows.\r
-\r
-regenerate-gtk-vsproj: Regenerate the GTK and libgail-util library\r
-projects.\r
-\r
-regenerate-all-msvc-projs: Re-generate all project files, and re-copy all \r
-the Visual Studio 2010 project files for VS 2012~2022.\r
-\r
-3) Using Meson (for Visual Studio and MinGW builds)\r
----\r
-\r
-Meson can now be used to build GTK+-3.x with either MinGW or Visual Studio.\r
-You will need the following items in addition to all the dependencies\r
-listed above:\r
-\r
-- Python 3.5 or later\r
-- Meson build system, 0.48.0 or later\r
-- Ninja (if not using the Visual Studio project generator for\r
- Visual Studio 2010, 2015, 2017, 2019)\r
-- CMake (optional, used for dependency searching)\r
-- pkg-config (optional, or some compatible tool, highly recommended)\r
-\r
-For all Windows builds, note that unless -Dbuiltin_immodules=no is specified,\r
-the input modules (immodules) are built directly into the GTK DLL.\r
-\r
-For building with Meson using Visual Studio, do the following:\r
-\r
-Create an empty build directory somewhere that is on the same drive\r
-as the source tree, and launch the Visual Studio command prompt that\r
-matches the build configuration (Visual Studio version and architecture),\r
-and run the following:\r
-\r
-- Ensure that both the installation directory of Python 3.5+ and its script\r
- directory is in your PATH, as well as the Ninja, CMake and pkg-config\r
- executables (if used). If a pkg-config compatible drop-in replacement\r
- tool is being used, ensure that PKG_CONFIG is set to point to the\r
- executable of that tool as well.\r
-\r
-- For non-GNOME dependencies (such as Cairo and Harfbuzz), where pkg-config\r
- files or CMake files could not be properly located, set INCLUDE and LIB\r
- to ensure that their header files and .lib files can be found respectively.\r
- The DLLs of those dependencies should also be in the PATH during the build\r
- as well, especially if introspection files are to be built.\r
-\r
-- For GNOME dependencies, the pkg-config files for those dependencies should\r
- be searchable by pkg-config (or a compatible tool). Verify this by running\r
- $(PKG_CONFIG) --modversion <dependency>.\r
-\r
-- Run the following:\r
- meson <path_to_directory_of_this_file> --buildtype=... --prefix=...,\r
- where buildtype can be release, debugoptimized, debug or plain. Please\r
- refer to the Meson documentation for more details. You may also wish to\r
- pass in -Dbroadway_backend=true if building the Broadway GDK backend is\r
- desired, and/or pass in -Dbuiltin_immodules=no to build the immodules as\r
- standalone DLLs that can be loaded by GTK dynamically. For Visual Studio\r
- 2010, 2015, 2017 and 2019 builds, you may pass in --backend=vs to generate\r
- Visual Studio project files to be used to carry out the builds.\r
-\r
-If you are building with Visual Studio 2008, note the following items as well:\r
-\r
-- For x64 builds, the compiler may hang when building the certain files, due\r
- to optimization issues in the compiler. If this happens, use the Windows\r
- Task Manager and terminate all cl.exe processes, and the build will fail\r
- with the source files that did not finish compiling due to the hang.\r
- Look for them in build.ninja in the build directory, and change their compiler\r
- flag "/O2" to "/O1", and the compilation and linking should proceed normally.\r
- At this time of writing, the following files are known to cause this hang:\r
-\r
- gtk\gtkfilechoosernativewin32.c\r
- gtk\gtkfilesystemmodel.c\r
- gtk\gtktextsegment.c\r
- gtk\gtktextbtree.c\r
- gtk\gtkrbtree.c\r
- testsuite\gtk\treemodel.c\r
- testsuite\gtk\textbuffer.c\r
- testsuite\gtk\rbtree.c\r
- testsuite\gtk\icontheme.c\r
-\r
-- Upon running install (via "ninja install"), it is likely that\r
- gtk-query-immodules-3.0.exe will fail to run as it cannot find msvcr90.dll or\r
- msvcr90D.dll. You can ignore this if you did not specify -Dbuiltin_immodules=no\r
- when configuring via Meson. If -Dbuiltin_immodules=no is specified, you need to\r
- run the following after embedding the manifests as outlined in the next point:\r
-\r
- <gtk_install_prefix>\bin\gtk-query-immodules-3.0.exe > <gtk_install_prefix>\lib\gtk-3.0\3.0.0\immodules.cache\r
-\r
-- You will need to run the following upon completing install, from the build\r
- directory in the Visual Studio 2008/SDK 6.0 command prompt (third line is not\r
- needed unless -Dbuiltin_immodules=no is specified) so that the built binaries\r
- can run:\r
-\r
- for /r %f in (*.dll.manifest) do if exist <gtk_install_prefix>\bin\%~nf mt /manifest %f /outputresource:<gtk_install_prefix>\bin\%~nf;2\r
- for /r %f in (*.exe.manifest) do if exist <gtk_install_prefix>\bin\%~nf mt /manifest %f /outputresource:<gtk_install_prefix>\bin\%~nf;1\r
- for /r %f in (*.dll.manifest) do if exist <gtk_install_prefix>\lib\gtk-3.0\3.0.0\immodules\%~nf mt /manifest %f /outputresource:<gtk_install_prefix>\lib\gtk-3.0\3.0.0\immodules\%~nf;2\r
-\r
-- The more modern visual style for the print dialog is not applied for Visual\r
- Studio 2008 builds. Any solutions to this is really appreciated.\r
-\r
-Support for pre-2012 Visual Studio\r
-==================================\r
-\r
-This release of GTK+ requires at least the Windows 8.0 SDK in order to be built\r
-successfully using Visual Studio, which means that building with Visual Studio\r
-2008 or 2010 is possible only with a special setup and must be done in the\r
-command line with Ninja. Please see\r
-https://devblogs.microsoft.com/cppblog/using-the-windows-software-development-kit-sdk-for-windows-8-consumer-preview-with-visual-studio-2010/\r
-for references; basically, assuming that your Windows 8.0 SDK is installed in\r
-`C:\Program Files (x86)\Windows Kits\8.0` (`$(WIN8SDKDIR)` in short), you need\r
-to ensure the following before invoking Meson to configure the build:\r
-\r
-- Your `%INCLUDE%` must not include the Windows 7.0/7.1 SDK include directories,\r
- and `$(WIN8SDKDIR)\include\um`, `$(WIN8SDKDIR)\include\um\share` and\r
- `$(WIN8SDKDIR)\include\winrt` (in this order) must be before your stock\r
- Visual Studio 2008/2010 header directories. If you have the DirectX SDK installed,\r
- you should remove its include directory from your `%INCLUDE%` as well.\r
-- You must replace the Windows 7.0/7.1 SDK library directory in `%LIB%` with the\r
- Windows 8.0 SDK library directory, i.e. `$(WIN8SDKDIR)\lib\win8\um\[x86|x64]`.\r
- If you have the DirectX SDK installed, you should remove its library directory\r
- from your `%INCLUDE%` as well.\r
-- You must replace the Windows 7.0/7.1 SDK tools directory from your `%PATH%` with\r
- the Windows 8.0 SDK tools directory, i.e. `$(WIN8SDKDIR)\bin\[x86|x64]`.\r
- If you have the DirectX SDK installed, you should remove its utility directory\r
- from your `%PATH%` as well.\r
-\r
-The Windows 8.0 SDK headers may contain an `roapi.h` that cannot be used under plain\r
-C, so to remedy that, change the following lines (around lines 55-57):\r
-\r
- // RegisterActivationFactory/RevokeActivationFactory registration cookie\r
- typedef struct {} *RO_REGISTRATION_COOKIE;\r
- // RegisterActivationFactory/DllGetActivationFactory callback\r
-\r
-to\r
-\r
- // RegisterActivationFactory/RevokeActivationFactory registration cookie\r
- #ifdef __cplusplus\r
- typedef struct {} *RO_REGISTRATION_COOKIE;\r
- #else\r
- typedef struct _RO_REGISTRATION_COOKIE *RO_REGISTRATION_COOKIE; /* make this header includable in C files */\r
- #endif\r
- // RegisterActivationFactory/DllGetActivationFactory callback\r
-\r
-This follows what is done in the Windows 8.1 SDK, which contains an `roapi.h`\r
-that is usable under plain C. Please note that you might need to copy that file\r
-into a location that is in your `%INCLUDE%` which precedes the include path for the\r
-Windows 8.0 SDK headers, if you do not have administrative privileges.\r
-\r
-Visual Studio 2008 hacks\r
-========================\r
-\r
-- You need to run the following lines from your build directory, to embed the\r
- manifests that are generated during the build, assuming the built binaries\r
- are installed to `$(PREFIX)`, after a successful build/installation:\r
-\r
-```cmd\r
-> for /r %f in (*.dll.manifest) do if exist $(PREFIX)\bin\%~nf mt /manifest %f (PREFIX)\bin\%~nf;2\r
-> for /r %f in (*.exe.manifest) do if exist $(PREFIX)\bin\%~nf mt /manifest %f (PREFIX)\bin\%~nf;1\r
-```\r
-\r
-\r
-- If building for amd64/x86_64/x64, sometimes the compilation of sources may seem to hang, which\r
- is caused by an optimization issue in the 2008 x64 compiler. You need to use Task Manager to\r
- remove all running instances of `cl.exe`, which will cause the build process to terminate. Update\r
- the build flags of the sources that hang on compilation by changing its `"/O2"` flag to `"/O1"`\r
- in `build.ninja`, and retry the build, where things should continue to build normally.\r
-\r
-Using GTK+ on Win32\r
-===================\r
-\r
-To use GTK+ on Win32, you also need either one of the above mentioned\r
-compilers. Other compilers might work, but don't count on it. Look for\r
-prebuilt developer packages (DLLs, import libraries, headers) on the\r
-above website.\r
-\r
-Multi-threaded use of GTK+ on Win32\r
-===================================\r
-\r
-Multi-threaded GTK+ programs might work on Windows in special simple\r
-cases, but not in general. Sorry. If you have all GTK+ and GDK calls\r
-in the same thread, it might work. Otherwise, probably not at\r
-all. Possible ways to fix this are being investigated.\r
-\r
---Tor Lillqvist <tml@iki.fi>, <tml@novell.com>\r
---Updated by Fan, Chun-wei <fanc999@yahoo.com.tw>\r
--- /dev/null
+Notes on running GTK on Windows in general
+===
+The Win32 backend in GTK+ is not as stable or correct as the X11 one.
+
+For prebuilt runtime and developer packages see
+http://ftp.gnome.org/pub/gnome/binaries/win32/
+
+Notes on using OpenGL (GtkGLArea/GdkGLArea) on Win32
+===
+Note that on Windows, if one is running Nahimic 3 on a system with
+nVidia graphics, one needs to stop the "Nahimic service" or insert
+the GTK application into the Nahimic blacklist, as noted in
+https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/297952/nahimic-and-nvidia-drivers-conflict/2334568/
+if using programs that utilise GtkGLArea and/or GdkGLArea, or use
+GDK_GL=gles if you know that GLES support is enabled for the build.
+
+This is a known issue, as the above link indicates, and affects quite
+a number of applications--sadly, since this issue lies within the
+nVidia graphics driver and/or the Nahimic 3 code, we are not able
+to rememdy this on the GTK side; the best bet before trying the above
+workarounds is to try to update your graphics drivers and Nahimic
+installation.
+
+Building GTK+ on Win32
+===
+
+First you obviously need developer packages for the compile-time
+dependencies: GDK-Pixbuf, Pango, atk, glib, gettext-runtime, libiconv at least.
+See http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies .
+
+For people compiling GTK+ with Visual C++, it is recommended that
+the same compiler is used for at least GDK-Pixbuf, Pango, atk and glib
+so that crashes and errors caused by different CRTs can be avoided.
+
+Currently building with Visual Studio 2008 or later is supported,
+either via Visual Studio project files or via the Meson build system,
+as described in the below sections.
+
+For Visual Studio 2008 and 2010, a special setup making use of the Windows
+8.0 SDK is required, see at the bottom of this document for guidance.
+Interchanging between Visual Studio 2015, 2017, 2019 and 2022 builds
+should be fine as they use the same CRT (UCRT) DLLs.
+
+After installing the dependencies, there are two ways to build GTK+
+for win32.
+
+GNU tools, ./configure && make install (info here may be out of date,
+consider using Meson instead)
+---
+
+This requires you have mingw and MSYS.
+
+Use the configure script, and the resulting Makefiles (which use
+libtool and gcc to do the compilation). I use this myself, but it can
+be hard to setup correctly.
+
+The full script I run to build GTK+ 2.16 unpacked from a source
+distribution is as below. This is from bulding GTK+ 2.16.5. I don't
+use any script like this to build the development branch, as I don't
+distribute any binaries from development branches.
+
+```
+# This is a shell script that calls functions and scripts from
+# tml@iki.fi's personal work envíronment. It is not expected to be
+# usable unmodified by others, and is included only for reference.
+
+MOD=gtk+
+VER=2.16.5
+REV=1
+ARCH=win32
+
+THIS=${MOD}_${VER}-${REV}_${ARCH}
+
+RUNZIP=${MOD}_${VER}-${REV}_${ARCH}.zip
+DEVZIP=${MOD}-dev_${VER}-${REV}_${ARCH}.zip
+
+HEX=`echo $THIS | md5sum | cut -d' ' -f1`
+TARGET=c:/devel/target/$HEX
+
+usedev
+usemsvs6
+
+(
+
+set -x
+
+DEPS=`latest --arch=${ARCH} glib atk cairo pango libpng zlib libtiff jpeg`
+PROXY_LIBINTL=`latest --arch=${ARCH} proxy-libintl`
+
+PKG_CONFIG_PATH=
+for D in $DEPS; do
+ PATH=/devel/dist/${ARCH}/$D/bin:$PATH
+ [ -d /devel/dist/${ARCH}/$D/lib/pkgconfig ] && PKG_CONFIG_PATH=/devel/dist/${ARCH}/$D/lib/pkgconfig:$PKG_CONFIG_PATH
+done
+
+LIBPNG=`latest --arch=${ARCH} libpng`
+ZLIB=`latest --arch=${ARCH} zlib`
+LIBTIFF=`latest --arch=${ARCH} libtiff`
+JPEG=`latest --arch=${ARCH} jpeg`
+
+patch -p0 <<'EOF'
+EOF
+
+lt_cv_deplibs_check_method='pass_all' \
+CC='gcc -mtune=pentium3 -mthreads' \
+CPPFLAGS="-I/devel/dist/${ARCH}/${LIBPNG}/include \
+-I/devel/dist/${ARCH}/${ZLIB}/include \
+-I/devel/dist/${ARCH}/${LIBTIFF}/include \
+-I/devel/dist/${ARCH}/${JPEG}/include \
+-I/devel/dist/${ARCH}/${PROXY_LIBINTL}/include" \
+LDFLAGS="-L/devel/dist/${ARCH}/${LIBPNG}/lib \
+-L/devel/dist/${ARCH}/${ZLIB}/lib \
+-L/devel/dist/${ARCH}/${LIBTIFF}/lib \
+-L/devel/dist/${ARCH}/${JPEG}/lib \
+-L/devel/dist/${ARCH}/${PROXY_LIBINTL}/lib -Wl,--exclude-libs=libintl.a \
+-Wl,--enable-auto-image-base" \
+LIBS=-lintl \
+CFLAGS=-O2 \
+./configure \
+--enable-win32-backend \
+--disable-gdiplus \
+--with-included-immodules \
+--without-libjasper \
+--enable-debug=yes \
+--enable-explicit-deps=no \
+--disable-gtk-doc \
+--disable-static \
+--prefix=$TARGET &&
+
+libtoolcacheize &&
+rm gtk/gtk.def &&
+(PATH="$PWD/gdk-pixbuf/.libs:/devel/target/$HEX/bin:$PATH" make -j3 install || (rm .libtool-cache* && PATH="/devel/target/$HEX/bin:$PATH" make -j3 install)) &&
+
+PATH="/devel/target/$HEX/bin:$PATH" gdk-pixbuf-query-loaders >/devel/target/$HEX/etc/gtk-2.0/gdk-pixbuf.loaders &&
+
+grep -v -E 'Automatically generated|Created by|LoaderDir =' <$TARGET/etc/gtk-2.0/gdk-pixbuf.loaders >$TARGET/etc/gtk-2.0/gdk-pixbuf.loaders.temp &&
+ mv $TARGET/etc/gtk-2.0/gdk-pixbuf.loaders.temp $TARGET/etc/gtk-2.0/gdk-pixbuf.loaders &&
+grep -v -E 'Automatically generated|Created by|ModulesPath =' <$TARGET/etc/gtk-2.0/gtk.immodules >$TARGET/etc/gtk-2.0/gtk.immodules.temp &&
+ mv $TARGET/etc/gtk-2.0/gtk.immodules.temp $TARGET/etc/gtk-2.0/gtk.immodules &&
+
+./gtk-zip.sh &&
+
+mv /tmp/${MOD}-${VER}.zip /tmp/$RUNZIP &&
+mv /tmp/${MOD}-dev-${VER}.zip /tmp/$DEVZIP
+
+) 2>&1 | tee /devel/src/tml/packaging/$THIS.log
+
+(cd /devel && zip /tmp/$DEVZIP src/tml/packaging/$THIS.{sh,log}) &&
+manifestify /tmp/$RUNZIP /tmp/$DEVZIP
+```
+
+You should not just copy the above blindly. There are some things in
+the script that are very specific to *my* build setup on *my* current
+machine. For instance the "latest" command, the "usedev" and
+"usemsvs6" shell functions, the `/devel/dist` folder. The above script
+is really just meant for reference, to give an idea. You really need
+to understand what things like `PKG_CONFIG_PATH` are and set them up
+properly after installing the dependencies before building GTK+.
+
+As you see above, after running configure, one can just say "make
+install", like on Unix. A post-build fix is needed, running
+gdk-pixbuf-query-loaders once more to get a correct `gdk-pixbuf.loaders`
+file.
+
+For a 64-bit build you need to remove the `gtk/gtk.def` file and let it
+be regenerated by the makefilery. This is because the 64-bit GTK dll
+has a slightly different list of exported function names. This is on
+purpose and not a bug. The API is the same at the source level, and
+the same #defines of some function names to actually have a _utf8
+suffix is used (just to keep the header simpler). But the
+corresponding non-suffixed function to maintain ABI stability are not
+needed in the 64-bit case (because there are no older EXEs around that
+would require such for ABI stability).
+
+
+Microsoft's tools
+---
+
+There are VS 2008~2022 solution and project files to build GTK+, which
+are maintained by Chun-wei Fan. They should build GTK+ out of the box,
+provided that the afore-mentioned dependencies are installed. They will
+build GDK with the Win32 backend, GTK+ itself (with GAIL/a11y built in),
+the GAIL-Util library and the gtk3-demo program. Please also refer to the
+README_FEATURES_MSVC.md file that reside in win32 on how to enable
+additional features that are not enabled by default, such as EGL support
+via libANGLE, which emulate the GL/EGL calls using Direct3D 9/11.
+
+Please refer to the following GNOME Live! page for a more detailed ouline
+on the process of building the GTK+ stack and its dependencies with Visual
+C++:
+
+https://wiki.gnome.org/Projects/GTK+/Win32/MSVCCompilationOfGTKStack
+
+Alternative 1 also generates Microsoft import libraries (.lib), if you
+have lib.exe available. It might also work for cross-compilation from
+Unix.
+
+I (Tor) use method 1 myself. Hans Breuer has been taking care of the MSVC
+makefiles. At times, we disagree a bit about various issues, and for
+instance the makefile.msc files might not produce identically named
+DLLs and import libraries as the "autoconfiscated" makefiles and
+libtool do. If this bothers you, you will have to fix the makefiles.
+
+If desiring to build binaries for ARM64 (`aarch64`), one needs to use the
+Visual Studio 2017 or 2019 or 2022 solution files, or use Meson with a
+cross-compilation file, with a Windows 10 SDK that supports ARM64
+builds. At this point, building the introspection files is not supported
+for ARM64 builds, and you will need a Python 3.x interpreter and
+glib-compile-resources binaries that run on the build machine.
+
+For Visual Studio 2017 ARM64 builds, do also check the
+`Directory.Build.props` file in `$(srcroot)/win32/vs15`
+indicates a Windows 10 SDK version that supports ARM64 builds
+exists on the build machine.
+
+For building ARM64 binaries with the Visual Studio projects, prior to the
+build, you may need to update `gtk3-gen-srcs.props` to pass in the variables:
+
+* GLIB_MKENUMS,
+* GLIB_GENMARSHAL
+* GDBUS_CODEGEN
+* GLIB_COMPILE_RESOURCES
+
+in the nmake command line indicated by `<GenerateRequiredSourcesBase>` so
+that they point to the respective tools and scripts that will run on the
+build machine. You may also need to update `gtk3-version-paths.props` to
+update `<PythonDir>` to the installation of the Python 3.x interpreter
+that will run on the build machine. To carry out the actual build using
+the solution files, use the "Configuration Manager" to add the
+ARM64 build configs by copying the settings from the x64 configs, and then
+build the solution.
+The build instructions for such builds otherwise follow the standard Win32
+(x86) and x64 builds, but you need to ensure that you have ARM64 builds of
+the various dependencies.
+
+It may still be possible to carry out the build and build the
+introspection files with Python 2.7.x using older versions of GLib and
+GObject-Introspection, but please note that this is not recommended
+and one is on his/her own by doing so.
+
+It is now supported to build with the Visual Studio projects directly
+from a GIT checkout. Run in a Visual Studio command prompt, in
+$(srcroot)/win32:
+
+`nmake /f bootstrap-msvc.mak [PYTHON=...] [PERL=...] [FONT_FEATURES_DEMO=1] [FONT_FEATURES_USE_PANGOFT2=1] [USE_EGL=1]`
+
+where `PYTHON` and `PERL` are the respective paths to the Python and PERL
+interpreters, if they are not in your `%PATH%`-they are both required to
+generate the full sets of project files, as well as the auxiliary build
+files and headers that is not available in a GIT checkout and must be
+generated prior to opening the project files.
+
+For `FONT_FEATURES_DEMO`, `FONT_FEATURES_USE_PANGOFT2` and `USE_EGL`,
+please refer to `win32\README_FEATURES_MSVC.md` for more details, to
+enable features that is optional and not enabled by default (i.e. in the
+release tarballs).
+
+It is also possible to regenerate some or all of the visual studio
+projects with the following, if necessary:
+
+`nmake /f generate-msvc.mak [PYTHON=...] [FONT_FEATURES_DEMO=1] [FONT_FEATURES_USE_PANGOFT2=1] [USE_EGL=1] <target>`
+
+Where target can be (they will update all related VS2008~2022 projects):
+
+* `regenerate-demos-h-win32`: Regenerate the `gtk3-demo` projects along
+ with `demos.h.win32`, useful to enable or disable the Font Features
+ demo.
+* `regenerate-gdk-vsproj`: Regenerate all the GDK projects with
+ `broadwayd`, useful to enable or disable EGL on Windows.
+* `regenerate-gtk-vsproj`: Regenerate the `gtk-3` and `gailutil-3` library
+ projects.
+* `regenerate-all-msvc-projs`: Re-generate all project files, and re-copy
+ all the Visual Studio 2010 project files for VS 2012~2022.
+
+Using Meson (for Visual Studio and MinGW builds)
+---
+
+Meson can now be used to build GTK+-3.x with either MinGW or Visual Studio.
+You will need the following items in addition to all the dependencies
+listed above:
+
+* Python 3.5 or later
+* Meson build system, 0.48.0 or later
+* Ninja (if not using the Visual Studio project generator for
+ Visual Studio 2010 or later)
+* CMake (optional, used for dependency searching)
+* pkg-config (optional, or some compatible tool, highly recommended)
+
+For all Windows builds, note that unless `-Dbuiltin_immodules=no` is
+specified, the input modules (immodules) are built directly into the GTK
+DLL.
+
+For building with Meson using Visual Studio, do the following:
+
+* Create an empty build directory somewhere that is on the same drive
+ as the source tree, and launch the Visual Studio command prompt that
+ matches the build configuration (Visual Studio version and architecture),
+ and run the following:
+
+* Ensure that both the installation directory of Python 3.5+ and its script
+ directory is in your `%PATH%`, as well as the Ninja, CMake and pkg-config
+ executables (if used). If a pkg-config compatible drop-in replacement
+ tool is being used, ensure that `PKG_CONFIG` is set to point to the
+ executable of that tool as well.
+
+* For non-GNOME dependencies (such as Cairo and Harfbuzz), where pkg-config
+ files or CMake files could not be properly located, set `%INCLUDE%` and
+ `%LIB%` to ensure that their header files and .lib files can be found
+ respectively. The DLLs of those dependencies should also be in the
+ `%PATH%` during the build as well, especially if introspection files ar
+ to be built.
+
+* For GNOME dependencies, the pkg-config files for those dependencies
+ should be searchable by `pkg-config` (or a compatible tool). Verify
+ this by running `$(PKG_CONFIG) --modversion <dependency>`.
+
+* Run the following:
+ `meson <path_to_directory_of_this_file> --buildtype=... --prefix=...,
+ where `buildtype` can be:
+
+ * release
+ * debugoptimized
+ * debug
+ * plain.
+
+ Please refer to the Meson documentation for more details. You may also
+ wish to pass in `-Dbroadway_backend=true` if building the Broadway GDK
+ backend is desired, and/or pass in `-Dbuiltin_immodules=no` to build the
+ immodules as standalone DLLs that can be loaded by GTK dynamically. For
+ Visual Studio 2010 or later builds, you may pass in --backend=vs to
+ generate Visual Studio project files to be used to carry out the builds.
+
+ If you are building with Visual Studio 2008, note the following items as
+ well:
+
+ * For x64 builds, the compiler may hang when building the certain
+ files, due to optimization issues in the compiler. If this happens,
+ use the Windows Task Manager and terminate all `cl.exe` processes,
+ and the build will fail with the source files that did not finish
+ compiling due to the hang. Look for them in build.ninja in the build
+ directory, and change their compiler
+ flag `/O2` to `/O1`, and the compilation and linking should proceed
+ normally.
+
+ * At this time of writing, the following files are known to cause this
+ hang:
+
+ * gtk\gtkfilechoosernativewin32.c
+ * gtk\gtkfilesystemmodel.c
+ * gtk\gtktextsegment.c
+ * gtk\gtktextbtree.c
+ * gtk\gtkrbtree.c
+ * testsuite\gtk\treemodel.c
+ * testsuite\gtk\textbuffer.c
+ * testsuite\gtk\rbtree.c
+ * testsuite\gtk\icontheme.c
+ * Upon running install (via "ninja install"), it is likely that
+ `gtk-query-immodules-3.0.exe` will fail to run as it cannot find
+ `msvcr90.dll` or `msvcr90D.dll`. You can ignore this if you did not
+ specify `-Dbuiltin_immodules=no` when configuring via Meson.
+ If `-Dbuiltin_immodules=no` is specified, you need to run the
+ following after embedding the manifests as outlined in the next
+ point:
+ `$(gtk_install_prefix)\bin\gtk-query-immodules-3.0.exe > $(gtk_install_prefix)\lib\gtk-3.0\3.0.0\immodules.cache`
+
+ * You will need to run the following upon completing install, from the
+ build directory in the Visual Studio 2008/SDK 6.0 command prompt
+ (third line is not needed unless `-Dbuiltin_immodules=no` is
+ specified) so that the built binaries can run:
+```
+ for /r %f in (*.dll.manifest) do if exist $(gtk_install_prefix)\bin\%~nf mt /manifest %f /outputresource:$(gtk_install_prefix)\bin\%~nf;2
+ for /r %f in (*.exe.manifest) do if exist $(gtk_install_prefix)\bin\%~nf mt /manifest %f /outputresource:$(gtk_install_prefix)\bin\%~nf;1
+ for /r %f in (*.dll.manifest) do if exist $(gtk_install_prefix)\lib\gtk-3.0\3.0.0\immodules\%~nf mt /manifest %f /outputresource:$(gtk_install_prefix)\lib\gtk-3.0\3.0.0\immodules\%~nf;2
+```
+
+ * The more modern visual style for the print dialog is not applied for
+ Visual Studio 2008 builds. Any solutions to this is really
+ appreciated.
+
+Support for all pre-2012 Visual Studio builds
+---
+
+This release of GTK+ requires at least the Windows 8.0 or later SDK in
+order to be built successfully using Visual Studio, which means that
+building with Visual Studio 2008 or 2010 is possible only with a special
+setup and must be done in the command line with Ninja, if using Meson.
+Please see
+https://devblogs.microsoft.com/cppblog/using-the-windows-software-development-kit-sdk-for-windows-8-consumer-preview-with-visual-studio-2010/
+for references; basically, assuming that your Windows 8.0 SDK is installed
+in `C:\Program Files (x86)\Windows Kits\8.0` (`$(WIN8SDKDIR)` in short),
+you need to ensure the following before invoking Meson to configure the build. Your project files or Visual Studio IDE must also be similarly
+configured (using the Windows 8.1 SDK is also possible for Visual Studio
+2008~2012, replacing `$(WIN8SDKDIR)` with `$(WIN81SDKDIR)`, which is in
+`C:\Program Files (x86)\Windows Kits\8.1` unless otherwise indicated):
+
+* Your `%INCLUDE%` (i.e. "Additional Include Directories" in the IDE)
+ must not include the Windows 7.0/7.1 SDK include directories,
+ and `$(WIN8SDKDIR)\include\um`, `$(WIN8SDKDIR)\include\um\share` and
+ `$(WIN8SDKDIR)\include\winrt` (in this order) must be before your stock
+ Visual Studio 2008/2010 header directories. If you have the DirectX
+ SDK (2010 June or earlier) installed, you should remove its include
+ directory from your `%INCLUDE%` as well.
+* You must replace the Windows 7.0/7.1 SDK library directory in `%LIB%`
+ (i.e. "Additional Library Paths" in the IDE) with the Windows 8.0/8.1
+ SDK library directory, i.e. `$(WIN8SDKDIR)\lib\win8\um\[x86|x64]` or
+ `$(WIN81SDKDIR)\lib\winv6.3\um\[x86|x64]`.
+ If you have the DirectX SDK installed, you should remove its library
+ directory from your `%LIB%` as well.
+* You must replace the Windows 7.0/7.1 SDK tools directory from your
+ `%PATH%` ("Executables Directories" in the IDE) with the Windows 8.0
+ SDK tools directory, i.e. `$(WIN8SDKDIR)\bin\[x86|x64]`. If you have
+ the DirectX SDK installed, you should remove its utility directory from
+ your `%PATH%` as well.
+
+* The Windows 8.0 SDK headers may contain an `roapi.h` that cannot be
+ used under plain C, so to remedy that, change the following lines
+ (around lines 55-57) (this is not necessary for the Windows 8.1 or
+ later SDKs):
+
+```
+ // RegisterActivationFactory/RevokeActivationFactory registration cookie
+ typedef struct {} *RO_REGISTRATION_COOKIE;
+ // RegisterActivationFactory/DllGetActivationFactory callback
+```
+
+to
+
+```
+ // RegisterActivationFactory/RevokeActivationFactory registration cookie
+ #ifdef __cplusplus
+ typedef struct {} *RO_REGISTRATION_COOKIE;
+ #else
+ typedef struct _RO_REGISTRATION_COOKIE *RO_REGISTRATION_COOKIE; /* make this header includable in C files */
+ #endif
+ // RegisterActivationFactory/DllGetActivationFactory callback
+```
+
+This follows what is done in the Windows 8.1 SDK, which contains an
+`roapi.h` that is usable under plain C. Please note that you might need
+to copy that file into a location that is in your `%INCLUDE%` which
+precedes the include path for the Windows 8.0 SDK headers, if you do not
+have administrative privileges.
+
+Visual Studio 2008 hacks
+---
+(Please see the section on Meson builds which touch on this topic)
+
+Multi-threaded use of GTK+ on Win32
+---
+
+Multi-threaded GTK+ programs might work on Windows in special simple
+cases, but not in general. Sorry. If you have all GTK+ and GDK calls
+in the same thread, it might work. Otherwise, probably not at
+all. Possible ways to fix this are being investigated.
+
+ * Tor Lillqvist <tml@iki.fi>, <tml@novell.com>
+ * Updated by Fan, Chun-wei <fanc999@yahoo.com.tw>
projects / gtk+3.0.git / commitdiff